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SECTION  1 


INTRODUCTION 


1.1  RATIONALE  FOR  THIS  INVESTIGATION 

The  growing  interest  in  using  Ada  as  a  Program  Design  Language 
(PDL)  as  well  as  an  implementation  language  has  led  to  several 
different  proposals  for  how  to  use  Ada  as  a  Design  Language.  More 
and  more  projects  require  the  use  of  Ada  as  a  PDL  in  an  attempt  to 
standardize  on  a  common  PDL  and  to  ease  the  transition  to  Ada  as  the 
implementation  (programming)  language*  Ada  is  much  more  rigorously 
defined  than  most  PDLs,  and  Ada  has  a  much  richer  set  of  constructs. 
Using  Ada  as  a  PDL  will  represent  a  major  change  to  most  current 
software  designers. 

Recently  the  government  software  development  and  documentation 
standards  have  changed  with  the  introduction  of  DOD-STD-2167  [D0D85] 
and  the  revisions  to  MIL-STD-483A,  MIL-STD-490A  and  MIL-STD-1521B. 
With  the  use  of  Ada  as  a  PDL  likely  in  some  of  the  documents  called 
for  in  DOD-STD-2167  and  its  associated  DIDs,  project  managers  need 
some  guidance  about  how  Ada  as  a  PDL  relates  to  the  other  design 
documentation.  Examples  of  the  use  of  Ada  as  a  PDL  and  a  documenta¬ 
tion  "boilerplate"  will  be  useful  to  current  and  future  projects. 

There  is  a  growing  awareness  in  the  software  development  field 
of  the  importance  of  formal  mathematical  methods  in  producing 
accurate  and  reliable  software.  Many  of  the  advanced  features  in 
Ada  (such  as  packages,  strong  typing  and  overloading)  were  included 
in  the  language  to  help  support  some  formal  methods.  While  the  Ada 
language  (as  defined  in  MIL-STD-1815A)  contains  support  for  some 
formal  methods,  there  are  other  formal  methods  that  are  not  directly 
supported  by  the  syntax  and  semantics  of  Ada.  Several  recent  Ada 
PDL  proposals  have  tried  to  improve  Ada's  support  of  these  missing 
formal  methods  through  extensions  to  the  language  and  through 
support  tools  [Inte84].  As  the  need  for  highly  accurate  and 
reliable  software  grows,  the  need  for  Ada  PDLs  that  support  many 
types  of  formal  methods  will  grow  also. 


1.2  APPROACH  TAKEN 

The  MITRE  Software  Center  decided  to  investigate  the  use  of  Ada 
as  a  Program  Design  Language  (PDL),  including  formal  methods  and 
within  a  DOD-STD-2167  framework,  by  performing  a  small  design  exer¬ 
cise.  The  problem  that  was  chosen  was  a  subset  of  the  functionality 
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of  the  APSE  Interactive  Monitor  (AIM)  [ TI83 ] •  Because  of  a  limit  on 
the  personnel,  resources  and  time  that  were  available,  only  a  very 
minimal  subset  of  the  AIM  functionality  was  implemented.  Our  system 
was  called  the  Micro  Interactive  Monitor  SYstem  (MIMSY). 

To  enhance  the  realism  of  the  design  exercise,  all  the  Software 
Center  personnel  who  participated  were  assigned  roles  corresponding 
to  the  acquisition  jobs  called  for  in  DOD-STD-2167.  One  person  was 
assigned  the  job  of  "customer , "  responsible  for  seeing  that  MIMSY 
can  perform  the  functions  required.  As  an  aid  to  the  design  process 
the  customer  was  assumed  to  be  knowledgeable  of  Ada  and  formal  meth¬ 
ods  as  well  as  MIMSY's  functionality.  While  this  may  not  always  be 
a  realistic  assumption  in  real  acquisitions,  having  a  knowledgeable 
customer  limited  the  amount  of  training  that  would  have  been  needed 
to  convince  the  customer  of  the  need  for  Ada  and  formal  methods. 

The  customer  had  an  "advisor"  to  provide  technical  guidance;  this 
advisor  corresponded  to  the  kind  of  support  that  MITRE  would  supply 
to  a  real  customer. 

The  remaining  participants  in  the  MIMSY  exercise  were  formed 
into  a  "contractor"  team  corresponding  to  an  independent  company 
that  had  been  awarded  the  MIMSY  contract.  Five  people,  all  with 
some  experience  in  using  Ada  and  formal  methods,  made  up  the  team 
that  actually  designed  MIMSY.  One  person  had  the  job  of  "project 
leader,"  with  overall  responsibili ty  for  getting  the  design  and  the 
documentation  done  on  time.  Another  person  had  the  responsibility 
for  Configuration  Management  (CM)  and  Quality  Assurance  (QA), 
corresponding  to  an  independent  CM/QA  department  within  the  con¬ 
tractor,  Three  other  people  were  the  designers  of  MIMSY.  They 
worked  collectively  designing  the  earliest  stages  of  MIMSY,  and  then 
later  worked  separately  on  designing  a  major  component  of  MIMSY. 

Most  of  the  documents  called  for  in  DOD-STD-2167  for  the  early 
stages  of  a  project's  development  were  produced.  This  included  a 
Statement  Of  Work  (SOW),  a  Software  Development  Plan  (SDP),  a 
Software  Requirements  Specification  (SRS)  and  a  Software  Top  Level 
Design  Document  (STLDD).  While  the  SDP  and  the  SRS  were  primarily 
English  text,  the  STLDD  was  primarily  Ada  PDL  text.  Both  iterations 
of  the  STLDD  were  approximately  40  pages  long,  with  85%  of  each 
document  being  Ada  PDL. 

To  more  easily  use  formal  methods  in  the  design  process,  a  PDL 
was  chosen  that  supports  a  wide  variety  of  formal  methods.  The  ANNA 
[Luck84]  language  was  chosen  because  it  is  based  on  Ada  and  because 
ANNA  has  support  for  formal  methods  missing  in  Ada  through  struc¬ 
tured  comments.  Work  is  currently  underway  at  Stanford  University 
on  tools  that  can  recognize  ANNA's  structured  comments  and  produce 
code  to  check  whether  design  constraints  are  being  met.  While  the 
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MIMSY  team  did  not  have  access  to  these  tools,  ANNA  was  used  anyway 
because  it  provided  a  precise  notation  for  expressing  the  design. 

The  current  version  of  ANNA  has  no  support  for  Ada  tasks  but  a 
tasking  constraint  language  called  TSL  [Helm85],  written  by  the  same 
computer  scientists  who  built  ANNA,  has  been  written  that  does 
support  design  using  Ada  tasks.  MIMSY  used  TSL  together  with  ANNA 
whenever  Ada  tasks  were  used  in  the  design. 

The  design  methodology  that  was  used  on  MIMSY  was  Buhr's  system 
design  methodology  [Buhr84]  with  Ada.  While  this  design  methodology 
makes  heavy  use  of  the  Ada  language  and  the  formal  methods  which  Ada 
directly  supports,  Buhr's  methodology  does  not  support  the  formal 
methods  that  ANNA  adds  to  Ada.  Rather  than  trying  to  develop  a 
design  methodology  specifically  for  ANNA  or  using  a  design  method¬ 
ology  specifically  created  to  use  a  wide  range  of  formal  methods, 
MIMSY  tried  to  use  ANNA's  formal  methods  with  an  existing  design 
methodology.  One  goal  of  the  MIMSY  project  was  to  see  how  well 
formal  methods  could  be  used  with  existing  design  methodologies. 

Formal  reviews  of  the  MIMSY  documentation  were  conducted  in 
accordance  with  DOD-STD-2167 .  The  SDP  and  the  SRS  were  reviewed  at 
a  Software  Specification  Review  (SSR).  Two  different  Preliminary 
Design  Reviews  (PDRs)  were  conducted  on  the  STLDD.  The  second  PDR 
was  needed  to  add  detail  and  answer  customer  questions  that  were 
raised  at  the  first  PDR.  In  addition  to  the  MIMSY  participants, 
outside  MITRE  personnel  were  invited  to  these  reviews  so  more  people 
could  see  the  advantages/problems  of  using  Ada,  ANNA,  formal  methods 
and  DOD-STD-2167  together. 
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SECTION  2 


MIMSY'S  FUNCTIONALITY 


2.1  OPERATIONS  TO  BE  PERFORMED 

When  completed,  the  MIMSY  system  will  allow  a  user  to  control 
the  output  of  one  or  more  Ada  applications  programs  on  the  screen  of 
a  terminal,  MIMSY  will  provide  a  primitive  horizontal  windowing 
capability  that  allows  a  user  to  set  aside  certain  lines  of  the 
screen  for  the  output  from  an  Ada  program,  and  then  be  able  to 
scroll  through  the  output  of  a  particular  window.  The  user  inter¬ 
face  and  appearance  on  the  screen  are  similar  to  that  of  DEC'S 
"lsedit"  editor  [DEC85a]  or  the  "emacs"  [Stal85]  editor. 

In  addition  to  a  primitive  window  manager,  MIMSY  allows  the 
user  to  control  the  Ada  applications  programs  that  are  creating  the 
output  being  displayed  in  the  windows,  A  user  can  create,  suspend, 
resume  and  terminate  an  Ada  applications  program  under  MIMSY's 
control.  While  MIMSY  was  required  to  be  portable  to  a  number  of 
different  Ada  operating  environments,  both  MIMSY  and  the  applica¬ 
tions  programs  that  it  is  controlling  were  assumed  to  be  implemented 
first  on  top  of  DEC'S  VMS  operating  system.  Development  of  MIMSY 
would  be  done  in  Ada  using  the  DEC  Ada  system  [DEC85b]. 

MIMSY's  functionality  is  a  subset  of  the  functionality  provided 
[ TI83 ] .  AIM  allowed  control  of  the  input  to  the  applications  pro¬ 
gram  as  well  as  the  output  from  them.  AIM  also  provided  a  user 
interface  to  the  full  CAIS  [KIT84]  functionality  while  MIMSY  pro¬ 
vides  only  a  small  subset.  With  the  completion  of  the  AIM  project, 
it  will  be  interesting  to  compare  its  approach  with  the  more  formal 
approach  taken  with  MIMSY. 


2.2  MAJOR  MIMSY  COMPONENTS 

There  are  four  major  components  to  the  MIMSY  system.  The 
interfaces  to  and  operations  performed  by  these  components  are 
discussed  in  detail  in  MIMSY's  STLDD.  A  brief  summary  of  these 
components'  functionality  is  included  below  as  a  point  of  reference 
for  this  presentation. 

The  Keyboard  Controller  processes  all  the  keystrokes  typed  at  a 
user's  keyboard.  This  component  handles  functions  such  as  echoing, 
command  line  editing  (backspace  key)  and  determination  of  command 
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completion  (newline  character).  Completed  commands  are  sent  to  the 
next  component  for  analysis. 

The  Command  Interpreter  validates  any  user  commands  for  cor¬ 
rectness.  MIMSY  has  a  few  well-defined  commands.  Any  misspellings 
or  non-existent  commands  are  reported  as  errors  to  the  user  through 
a  message  displayed  on  the  terminal's  screen.  The  user  often  refers 
to  previously  created  screen  windows  and  applications  processes  in 
commands;  the  Command  Interpreter  ensures  that  these  names  are  still 
valid  references. 

The  Structure  Manager  encapsulates  the  control  of  the  main  data 
structures  in  MIMSY.  This  includes  the  data  structures  controlling 
the  positioning  and  contents  of  the  windows  on  the  screen,  and  the 
structures  that  control  the  applications  programs.  MIMSY  makes 
extensive  use  of  tasking  in  these  data  structures  to  maximize  con¬ 
currency  between  the  applications  programs. 

The  CAISette  component  is  an  attempt  to  provide  an  operating 
system-independent  interface  to  the  underlying  support  environment. 
The  CAIS  [KIT84]  is  an  example  of  such  an  interface  for  Ada  pro¬ 
grams,  but  MIMSY  did  not  need  all  the  CAIS  functionality.  To  mini¬ 
mize  the  amount  of  work  that  would  be  needed  on  this  interface,  a 
CAISette  was  defined  that  contained  only  those  CAIS  functions 
necessary  to  support  MIMSY.  The  CAISette  defines  not  only  the 
functional  interface  but  also  the  behavioral  model  of  the  underlying 
support  environment,  so  anyone  porting  MIMSY  to  another  environment 
will  be  aware  of  what  MIMSY  assumes  about  its  environment. 
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SECTION  3 


DESIGN  METHODOLOGY  USED  WITH  MIMSY 


3.1  DESCRIPTION  OF  DESIGN  METHODOLOGY 

The  design  methodology  used  during  the  design  phase  of  MIMSY 
was  an  actor  and  object  oriented  methodology  similar  to  those  used 
in  SMALLTALK  [Gold83]  and  PAMELA  [Cher85].  The  design  methodology 
makes  extensive  use  of  Ada  tasking,  with  active  tasks  initiating 
operations  and  passive  tasks  providing  services.  Each  of  the  major 
MIMSY  components  was  designed  as  a  task,  with  the  task  entry  points 
and  parameters  defining  the  messages  that  could  be  passed  between 
tasks.  Major  objects  within  each  component  were  also  designed  as 
tasks,  although  the  details  of  the  tasking  structure  within  a  major 
component  were  hidden  from  the  other  components. 

An  important  part  of  the  design  methodology  is  to  identify 
which  tasks  are  active  and  which  are  passive.  Since  MIMSY' s  primary 
function  is  to  respond  to  commands  typed  by  a  user,  the  KEYBOARD 
CONTROLLER  component  was  made  the  primary  active  object.  All  the 
other  components  of  MIMSY  serve  the  requests  generated  by  the 
KEYBOARD  CONTROLLER  (and  therefore  the  user). 

MIMSY  is  required  to  manage  the  user's  terminal  screen,  pro¬ 
viding  multi-windowing  for  multiple  user  programs.  This  requires 
the  management  of  data  flows  to  and  from  multiple  concurrent  user 
programs,  yet  at  the  same  time  managing  the  display  of  a  terminal 
screen  that  must  be  updated  sequentially.  To  minimize  the  complex¬ 
ity  of  the  data  flows  in  MIMSY,  the  design  methodology  calls  for 
each  of  the  major  data  structures  to  have  its  own  task  to  manage  it. 
The  STRUCTURE  MANAGER  component  of  MIMSY  is  responsible  for  the  data 
structures  that  control  the  windows  on  the  screen  and  the  user's 
programs.  This  design  methodology  leads  to  a  STRUCTURE  MANAGER  that 
is  a  hierarchy  of  data  structures  and  objects  (and  their  tasks)  that 
are  dynamically  created  and  destroyed  (terminated)  in  response  to 
user  commands. 

The  design  methodology  uses  extensive  data  abstraction,  where 
all  the  data  structures  and  objects  are  defined  in  terms  of  the 
operations  that  can  be  performed  on  them.  Data  abstraction  calls 
for  restrictions  to  be  placed  on  the  operations  on  the  data  types. 

In  MIMSY' s  case  these  restrictions  had  both  a  static  and  a  dynamic 
component.  Static  restrictions  are  the  classical  enumerations  of 
the  operations  that  are  allowed  and  the  allowable  range  of  values  on 
the  data  types.  Dynamic  restrictions  depend  on  the  current  state  of 
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the  data  types  and  objects.  These  dynamic  restrictions  are  typi¬ 
cally  represented  as  axioms  that  relate  previous  states  with  what 
are  now  legal  operations  on  the  data  types.  In  a  system  like  MIMSY, 
the  extensive  use  of  tasking  can  lead  to  rapidly  changing  states. 

The  design  methodology  tries  to  limit  the  complexity  of  the  data 
type  restrictions  by  structuring  the  objects  (and  their  tasks)  so 
the  restrictions  can  be  expressed  in  a  hierarchy. 


3.2  DESCRIPTION  OF  DESIGN  NOTATION 

The  design  methodology  described  in  the  previous  section 
results  in  a  variety  of  design  products  that  are  used  to  capture 
design  decisions  for  the  benefit  of  the  coders,  reviewers  (custo¬ 
mer),  designers  and  future  maintainers.  Two  different  design 
notations  were  used  to  capture  MIMSY' s  design.  These  two  design 
notations  try  to  find  a  balance  between  a  high  level  pictorial 
representation  of  the  design  (used  to  rapidly  convey  the  essence  of 
the  design)  and  a  detailed  description  of  the  design  (used  to  docu¬ 
ment  detailed  design  decisions). 

The  highest  levels  of  MIMSY' s  design  was  represented  with  Buhr 
diagrams  [Buhr84).  Buhr  diagrams  provide  a  series  of  graphical 
icons  that  may  be  connected  to  show  the  flow  of  control  and  data  in 
a  design.  The  complexity  of  a  design  (i.e.,  cluttered  pictures)  can 
be  limited  through  hierarchies  of  Buhr  diagrams.  Buhr  defines  a 
one-to-one  mapping  between  the  icons  of  the  graphical  representation 
and  the  Ada  code  skeletons  that  can  represent  the  icons.  The  icons 
for  Ada  tasks  are  especially  expressive,  allowing  a  designer  to 
capture  the  behavior  of  tasks  by  graphically  expressing  the  nature 
of  a  task's  entry  calls  (selective  entry,  timed  wait,  etc.). 

The  lower  (and  more  detailed)  levels  of  MIMSY' s  design  were 
represented  in  ANNA  text  [Luck84].  While  Buhr  diagrams  can  be  used 
to  express  the  structure  of  the  Ada  packages,  tasks  and  subprograms, 
the  diagrams  do  not  allow  the  structure  of  data  or  the  restrictions 
on  subprogram  calls  to  be  expressed.  Preconditions,  postconditions, 
exception  propagation  rules  and  other  detailed  design  decisions  were 
captured  in  ANNA  text. 

Currently  the  ANNA  language  cannot  be  used  to  express  restric¬ 
tions  on  the  actions  of  Ada  tasks  that  might  exist  in  the  design. 
This  shortcoming  has  been  overcome  by  ANNA's  companion  language,  the 
Task  Sequencing  Language  (TSL)  [Helm85].  TSL  was  defined  as  an 
extension  to  ANNA,  so  TSL  and  ANNA  text  may  be  combined  in  the  same 
design.  TSL  allows  restrictions  on  the  actions  of  Ada  tasks  to  be 
defined,  much  like  ANNA  allows  restrictions  on  the  actions  of 
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subprograms  and  packages  to  be  defined.  MIMSY's  designers  used  ANNA 
and  TSL  together  to  capture  the  details  of  how  the  system  was  to 
function. 

ANNA  has  no  support  for  capturing  the  design  management  infor¬ 
mation  called  for  in  DOD-STD-2167 ,  so  MIMSY's  designers  invented 
their  own  constructs  for  capturing  such  information.  In  MIMSY's 
case,  structured  comments  were  used  with  the  V'  character  used  as 
the  sentinel  character.  Design  management  information,  such  as 
requirements  traceability  and  change  logs,  consisted  of  a  reserved 
keyword  (such  as  "Change  Log")  followed  by  a  natural  language 
description  of  the  design  management  information.  Additional  sup¬ 
port  tools  could  have  been  built  to  extract  this  information  and 
create  management  reports  and/or  the  documentation  called  for  in 
DOD-STD-2167. 

MIMSY's  designers  worked  from  a  high  level  description  of  the 
system  to  a  detailed  description.  MIMSY's  design  was  first  docu¬ 
mented  at  a  high  level  with  Buhr  diagrams.  A  single  high  level 
diagram  of  the  MIMSY  system  was  broken  down  into  a  Buhr  diagram  for 
each  of  the  four  major  MIMSY  components.  Each  of  the  component's 
Buhr  diagrams  was  further  broken  down  into  more  detailed  Buhr 
diagrams.  The  most  detailed  Buhr  diagrams  describe  all  the  tasks 
that  exist  in  MIMSY  and  all  the  major  subprograms  that  implement 
MIMSY  functionality. 

With  the  graphical  representation  of  the  design  complete,  the 
designers  then  began  to  transcribe  the  diagrams  into  PDL  text.  The 
Buhr  diagrams  have  a  mapping  to  Ada  constructs  defined  for  them,  so 
the  designers  had  little  trouble  creating  Ada  package  and  subprogram 
specifications  from  the  diagrams.  The  designers  then  added  the  ANNA 
and  TSL  text  into  the  Ada  text  created  from  the  diagrams.  The  ANNA 
and  TSL  text  captured  the  increased  detail,  restrictions  and  system 
behavior  that  could  not  be  represented  in  the  diagrams. 

The  ANNA  and  TSL  text  had  the  same  organization  as  the  MIMSY 
components  and  subcomponents,  so  each  component  had  its  own  collec¬ 
tion  of  ANNA  and  TSL  text  that  described  its  design.  The  most  com¬ 
mon  method  used  by  a  MIMSY  designer  to  show  that  the  ANNA  and  TSL 
text  for  a  component  was  consistent  was  proof  by  induction.  Most  of 
these  inductive  proofs  used  a  few  basis  cases  then  recursive  induc¬ 
tion  steps  that  were  similar  to  Lisp  code. 


3.3  RATIONALE  FOR  USING  THIS  DESIGN  METHODOLOGY 

The  design  methodology  and  design  notations  used  in  MIMSY  pro¬ 
vided  a  good  match  between  the  needs  to  design  a  system  and  fulfill 
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the  original  requirements  of  the  MIMSY  investigation  (as  outlined  in 
Section  I  of  this  document).  The  methods  and  notations  were  very 
"Ada-like"  in  that  the  syntax  and  semantics  of  the  Ada  language  was 
used  as  much  as  possible.  The  addition  of  the  fbrmal  notations  of 
ANNA  and  TSL  just  completes  the  formalization  process  begun  by  using 
Ada  as  a  PDL. 

The  design  methodology  used  in  MIMSY  was  chosen  because  it 
allows  the  system  behavior  as  well  as  the  system's  structure  to  be 
expressed  in  Ada  PDL.  Used  properly,  Ada  tasking  can  be  the  most 
expressive  notation  to  describe  a  system's  behavior.  MIMSY  has 
extensive  requirements  for  the  independence  and  concurrency  of  the 
windows,  user  tasks,  keyboard,  etc.  The  Ada  language  defines  almost 
every  construct  of  the  language  except  task  entries  as  being  re¬ 
entrant.  One  goal  of  the  designers  was  to  make  the  components  of 
MIMSY  as  reentrant  as  possible,  with  those  parts  of  the  system  that 
must  have  their  actions  serialized  controlled  by  tasks.  The  design 
methodology ' s  use  of  the  Ada  task  as  the  primary  design  paradigm 
does  not  artificially  constrain  the  designers  in  their  use  of  Ada. 

Both  the  Buhr  graphical  notation  and  ANNA/TSL  make  extensive 
use  of  the  syntax  and  semantics  of  the  Ada  language.  Their  con¬ 
structs  are  the  same  as  the  constructs  provided  in  the  Ada  language. 
Neither  is  an  attempt  to  graft  some  other  design  paradigms  or  con¬ 
structs  on  the  Ada  language;  as  a  result,  designers  who  are  familiar 
with  Ada  have  less  difficulty  in  working  with  Buhr  and  ANNA.  If  Ada 
is  really  going  to  be  used  as  a  PDL,  then  any  annotations  and  gra¬ 
phical  representat ions  used  with  Ada  should  be  based  on  the  Ada 
language. 

DOD-STD-2167  implies  the  use  of  a  top-down  design  methodology, 
although  it  is  possible  to  use  it  with  other  design  methodologies 
such  as  bottom-up.  The  method  of  starting  with  increasingly 
detailed  Buhr  diagrams  and  then  moving  to  Ada/ANNA/TSL  text  fits  the 
description  of  a  top-down  methodology.  Since  many  systems  are  also 
developed  using  a  top-down  methodology,  the  lessons  learned  in  MIMSY 
have  some  applicability  to  real  system  designs.  This  may  change  in 
the  future  when  large  libraries  of  reusable  Ada  (or  ANNA)  packages 
allow  many  systems  to  be  designed  from  the  bottom  up. 

Many  existing  design  methodologies  and  notations  make  extensive 
use  of  graphics.  Designers  find  graphics  to  be  a  convenient  way  to 
express  a  system's  design  in  just  a  few  pages,  particularly  to  non¬ 
technical  reviewers.  The  introduction  of  Ada  as  a  PDL  will  not  (and 
should  not)  change  a  designer's  preference  for  the  use  of  graphical 
notations,  especially  at  the  highest  levels  of  a  design.  MIMSY 
chose  to  use  graphical  notation  in  its  designs.  Buhr  diagrams  were 
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chosen  because  they  were  the  most  expressive  notation  that  was 
well-integrated  with  the  Ada  language. 

The  use  of  ANNA  and  TSL  to  formally  define  the  restrictions  and 
behavior  of  MIMSY  provided  the  designers  with  an  opportunity  to  see 
how  the  increased  use  of  formal  methods  might  improve  a  design.  One 
problem  with  many  designs  is  that  important  design  decisions  are 
either  ambiguously  captured  or  are  not  written  down  at  all  (remain¬ 
ing  inside  the  designer's  head).  When  a  coder  or  maintainer  at¬ 
tempts  to  change  the  system  at  some  point  in  the  future,  the  lack  of 
complete  design  documentation  may  lead  to  the  introduction  of  errors 
and/or  excessive  maintenance  costs.  One  of  MIMSY' s  major  require¬ 
ments  was  that  it  be  maintainable;  the  introduction  of  formal 
methods  into  the  design  is  an  attempt  to  make  the  system  more  main¬ 
tainable.  ANNA  and  TSL  were  created  to  improve  Ada's  support  for 
formal  methods.  MIMSY' s  designers  decided  to  use  them  as  they  pro¬ 
vided  the  best  opportunity  to  increase  formalism  in  Ada  PDLs. 
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SECTION  4 


RELATIONSHIP  OF  ANNA  TO  FORMAL  METHODS 


4.1  ANNA  IMPROVES  ADA'S  COVERAGE  OF  FORMAL  METHODS 

While  Ada's  constructs  provide  support  for  many  formal  methods, 
there  are  some  formal  methods  that  Ada  does  not  cover.  ANNA  tries 
to  improve  Ada's  coverage  of  formal  methods  by  providing  new  and 
modified  constructs  that  a  designer  or  coder  can  use  with  Ada.  The 
constructs  described  below  allow  a  designer  to  use  some  of  the 
classical  techniques  of  formal  methods  with  systems  written  in  Ada. 

ANNA  provides  the  constructs  to  allow  the  use  of  first  order 
predicate  logic  in  Ada.  The  "exists”  and  "for  all"  quantifiers 
allow  a  designer  to  formally  specify  restrictions  on  an  Ada  data 
type,  important  if  abstract  data  types  are  to  be  used  extensively. 
ANNA  allows  the  use  of  logical  implication  and  equivalence  operators 
in  quantified  expressions. 

While  Ada's  strong  type  checking  provides  one  level  of  precon¬ 
ditions  and  postconditions,  ANNA  provides  the  constructs  for  the 
full  use  of  preconditions  and  postconditions  beyond  type  checking. 
Annotations  can  be  placed  on  individual  statements  (as  in  classical 
weakest  precondition  notations),  on  groups  of  statements  (e.g.,  for 
loop  invariants)  and  on  Ada  subprograms  and  packages.  ANNA  provides 
constructs  for  defining  the  propagation  of  Ada  exceptions,  which 
allows  both  the  designer  and  user  of  an  Ada  construct  to  know 
exactly  what  conditions  may  lead  to  an  exception  and  what  the  state 
of  the  software  will  be  if  exceptions  are  propagated. 

Ada  packages  will  tend  to  be  the  primary  means  of  organizing  an 
Ada  program.  Systems  built  with  Ada  will  be  hierarchies  of  (re¬ 
usable)  Ada  packages.  Just  as  packages  are  the  primary  building 
block  of  Ada,  packages  are  also  the  primary  building  block  of  ANNA. 
The  main  ANNA  constructs  for  describing  restrictions  and  system 
behavior  are  package  annotations,  so  there  is  no  separation  between 
the  primary  building  blocks  of  Ada  and  ANNA. 

ANNA  provides  the  additional  constructs  to  allow  axiomatic 
descriptions  of  a  package's  behavior  to  be  built.  These  axioms  can 
be  used  to  specify  how  the  subprograms,  data  types  and  objects  of  a 
package  relate  to  one  another.  Mathematical  induction  can  be  used 
to  define  the  actions  of  a  package  after  many  state  changes  have 
occurred . 
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4.2  ANNA  IS  WELL-INTEGRATED  INTO  ADA 


ANNA  was  designed,  constructed  and  documented  to  allow  ANNA 
annotations  to  be  fully  integrated  with  MIL-STD-1815A  Ada  [DOD83]. 
ANNA's  reference  manual  [Luck.84]  has  the  same  organization  [DOD83]. 
All  the  new  ANNA  constructs  are  defined  as  extensions  to  Ada's 
syntax  and  semantics.  Note  that  ANNA  inherits  some  of  Ada's  short¬ 
comings  as  well.  For  example,  Ada  programs  have  been  shown  to  be 
very  difficult  to  formally  verify  for  correctness  because  of  Ada's 
support  for  type  attributes,  tasking,  etc.  ANNA  was  not  designed  to 
solve  all  of  Ada's  problems;  instead  ANNA  provides  more  annotations 
to  the  existing  Ada  semantics  to  provide  improved  formal  methods 
support . 

All  ANNA  constructs  are  defined  as  a  syntax  that  appears  inside 
Ada  comments.  Unique  sentinel  characters  are  placed  after  the  Ada 
" — "  comment  indication.  For  ANNA  this  sentinel  character  is  ' | ' 

(or  '!')  and  for  TSL  the  character  is  '+'.  This  means  that  an 

Ada  compiler  is  unaffected  by  ANNA's  and  TSL's  statements  because 
they  are  hidden  inside  comments.  Only  ANNA/TSL  tools  (and  human 
readers)  use  these  statements  to  further  explain  the  program. 

ANNA  provides  constructs  for  annotating  almost  all  of  Ada's 
constructs,  tasks  being  the  major  exception.  Ada's  access  types, 
records,  exceptions,  generics,  packages  and  other  constructs  all 
have  ANNA  constructs  associated  with  them.  Because  ANNA  (with  TSL) 
covers  the  entire  Ada  language,  designers  and  coders  using  Ada  are 
not  tempted  to  use  subsets  of  Ada  in  an  attempt  to  stay  within  the 
annotation  language's  limitations.  ANNA  does  not  try  to  "glue  on" 
the  formalism  of  some  existing  formal  methods  system;  ANNA  has  been 
created  just  to  deal  with  Ada.  As  a  result,  designers  who  under¬ 
stand  Ada's  model  of  computation  will  have  less  difficulty  using 
ANNA  than  trying  to  use  some  other  annotation  language  that  was 
originally  built  for  a  different  model  of  computation. 

The  semantics  for  the  elaboration,  visibility,  scope  and  other 
attributes  of  ANNA  statements  are  the  same  as  for  the  Ada  constructs 
they  are  annotating  (TSL  uses  different  scope  and  visibility  rules). 
The  ANNA  reference  manual  [Luck84]  shows  that  each  ANNA  statement 
could  be  replaced  in-line  by  Ada  statements  that  would  actually  do 
the  checking  done  by  the  ANNA  statement.  This  mapping  would  not  be 
possible  if  ANNA  statements  were  outside  Ada's  semantics. 

In  many  instances  the  restriction  a  designer  might  want  to 
place  on  the  behavior  of  an  Ada  construct  might  be  expressed  through 
some  additional  Ada  text.  ANNA  allows  designers  to  place  additional 
Ada  text  (called  "virtual  Ada")  in  Ada  designs.  Virtual  Ada  has  the 
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same  syntax  and  semantics  as  regular  Ada,  the  only  difference  being 
that  virtual  Ada  is  placed  in  structured  comments  that  have  the 
character  as  the  sentinel  character.  Virtual  Ada  can  be  used  in 
combination  with  ANNA  text;  together  they  can  be  used  to  create  very 
expressive  specification  of  the  non-commentary  Ada  text. 


4.3  TSL  COVERS  ADA  TASKING 

Currently  the  ANNA  language  does  not  cover  Ada  tasks.  Instead, 
tasks  are  covered  by  a  separate  but  compatible  annotation  language 
called  TSL.  TSL  could  be  used  only  with  Ada  tasking  constructs 
(task,  task  types,  entries)  but  recent  changes  to  TSL  allow  it  to  be 
used  with  other  Ada  constructs  such  as  subprograms. 

TSL  assumes  that  all  the  "events”  associated  with  Ada  tasking 
can  be  placed  into  a  single  stream.  This  stream  of  "events"  would 
contain  all  the  task  creations  and  terminations,  entry  calls, 
accepts  and  rendezvous,  etc.  TSL  allows  the  designer  to  restrict 
the  ordering  of  events  in  the  event  stream.  These  restrictions  can 
be  used  by  a  designer  to  prevent  common  concurrency  problems  such  as 
deadlock.  TSL  annotations  can  also  be  used  to  better  specify  the 
conditions  that  a  task  expects  to  see  at  some  point  in  its 
execution. 

While  ANNA  is  oriented  to  both  static  and  dynamic  analysis  of 
Ada  programs,  TSL  is  oriented  almost  entirely  towards  dynamic 
analysis.  The  non-determinism  in  Ada's  tasking  model  makes  it  very 
difficult  to  predict  ahead  of  time  the  exact  ordering  of  events  in 
the  Ada  task  event  sequence.  TSL  provides  a  notation  that  allows 
run-time  monitors  to  catch  incorrect  sequences  of  task  events. 

Because  there  is  only  one  task  event  sequence,  the  sequence  may 
contain  events  of  tasks  that  are  not  of  interest  to  TSL  statements. 
TSL  handles  this  and  other  complications  of  checking  the  sequence  of 
events  in  much  the  same  way  as  Prolog  [Cloc81]  handles  the  search  of 
its  data  base.  As  with  Prolog,  TSL  statements  define  a  "pattern" 
that  is  matched  against  the  actual  contents  of  the  event  sequence. 
TSL  has  operators  similar  to  Prolog's  "cut"  that  can  be  used  to 
limit  the  complexity  of  the  event  sequence  matching.  This  contrast 
between  TSL 's  Prolog-like  approach  and  ANNA's  predicate  calculus 
approach  helps  explain  why  ANNA  and  TSL  are  currently  two  separate 
languages. 

While  the  ANNA  language's  definition  [Luck84]  is  stable  at  this 
point,  the  language  definition  of  TSL  [Helm85]  is  still  subject  to 
change.  For  example,  based  on  the  experiences  of  early  TSL  users 
(such  as  MIMSY),  TSL  has  added  user-defined  "events"  to  the  type  of 


15 


events  that  can  be  placed  in  the  task  event  sequence.  This  allows  a 
user  to  place  events  such  as  certain  subprogram  calls  or  changes  to 
key  objects  with  the  other  tasking  events  such  as  accepts  and 
releases . 


4.4  ANNA  USABLE  WITH  DIFFERENT  APPROACHES 

There  are  many  different  approaches  to  using  a  formal  method  to 
design  software.  For  example,  the  use  of  data  abstraction  can  be 
broken  down  into  the  algebraic  specification  approach  versus  the 
abstract  model  approach  [Berg82].  Each  approach  has  its  own  advan¬ 
tages  and  disadvantages;  ANNA  can  be  used  with  either  approach. 

The  algebraic  specification  approach  builds  the  description  of 
the  data  abstraction  from  low-level  axioms.  ANNA  package  axioms  can 
be  used  to  provide  these  low-level  axioms  for  an  Ada  abstract  data 
type.  Since  ANNA's  package  axioms  use  a  form  similar  to  classical 
data  type  axioms,  a  designer  experienced  in  the  classical  forms  has 
little  difficultly  in  learning  to  use  ANNA's  axioms. 

The  abstract  model  approach  builds  the  abstract  data  type  from 
previously  defined  (and  proven)  data  types  and  concepts.  These  pre¬ 
viously  defined  data  types  provide  a  model  on  which  the  new  abstract 
data  type  is  built.  An  Ada  programmer  might  view  this  approach  as 
an  example  of  reusability. 

ANNA  supports  the  abstract  model  approach  by  reusable  Ada 
libraries  that  encapsulate  (or  model)  the  concept  needed  by  the 
abstract  data  type  under  construction.  For  example,  a  library  can 
contain  the  Ada  functions  and  ANNA  axioms  to  check  whether  an 
abstract  data  type  has  the  properties  of  a  group  or  monoid.  This 
library  would  be  built  as  a  "virtual”  Ada  package,  allowing  for 
reusability.  If  designers  have  some  of  these  reusable  libraries  at 
their  disposal,  the  specification  of  the  properties  of  a  new 
abstract  data  type  becomes  less  verbose  than  if  all  the  individual 
axioms  had  to  be  repeated. 

In  formal  methods  the  full  specification  of  how  a  system  is 
supposed  to  work  is  built  up  on  layers  of  theorems  and  lemmas.  The 
proof  that  the  system  meets  its  specification  can  be  done  by  first 
proving  the  lower  level  theorems  (by  showing  that  all  the  axioms  and 
conditions  hold)  and  then  showing  that  the  lower  level  theorems 
prove  the  correctness  of  the  higher  level  theorems  and  then  finally 
the  entire  system.  ANNA  supports  this  approach  because  the  software 
can  be  built  with  layers  of  Ada  packages.  If  the  lower  level 
packages  can  be  shown  to  be  consistent  with  the  higher  level  ones, 
the  entire  system  can  be  shown  to  have  the  correct  behavior. 
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4.5  AN  ANNA  EXAMPLE  FROM  MIMSY 


Appendix  A  of  this  document  (Figures  1  and  2)  contains  an 
example  of  some  ANNA  text  that  was  written  for  the  MIMSY  project. 

In  this  case,  it  is  part  of  the  annotation  for  the  STRUCTURE  MANAGER 
component  of  MIMSY.  The  text  shown  is  part  of  the  package  specifi¬ 
cation  for  STRUCTURE  MANAGER;  the  real  package  specification  is  more 
verbose.  Some  of  the  details  have  been  eliminated  so  the  highlights 
of  the  package  can  be  seen. 

In  this  example  the  preconditions  and  axioms  are  trying  to  show 
that  the  first  thing  that  a  user  of  this  package  must  do  is  call 
START;  attempts  to  ANALYZE  a  COMMAND  or  TERMINATE  are  illegal.  One 
of  the  things  the  START  procedure  does  is  establish  the  MAXIMUM 
NUMBER  OF  screen  VIEWPORTS  and  user  PROCESSES  that  can  exist  at  any 
one  time.  Once  these  numbers  have  been  established,  they  must  not 
be  changed  by  a  call  to  ANALYZE  COMMAND.  Calls  to  START  after  the 
initial  call  are  illegal.  A  call  to  TERMINATE^ALL  prevents  any 
further  calls  to  the  main  procedure  of  STRUCTURE  MANAGER,  which  is 
ANALYZE_COMMAND . 

Note  the  use  of  induction  inside  the  axioms  for  this  package. 
The  two  axioms  for  ANALYZECOMMAND  show  that  the  maximum  number  of 
viewports  and  processes  remain  the  same  no  matter  what  kind  of 
ANALYZE_COMMAND  is  issued.  The  "for  all  C  :  COMMANDJRECORDS"  allows 
this  to  be  stated  for  any  type  of  command  that  was  analyzed. 


4.6  ANNA  TOOLS 

Currently  ANNA  is  useful  primarily  as  a  rigorous  notation  that 
designers  can  use  to  specify  the  behavior  of  Ada  software.  ANNA's 
situation  is  similar  to  that  of  Ada's  before  the  availability  of 
robust,  validated  Ada  compilers.  The  rigor  of  the  notation  makes  it 
useful  to  those  software  engineers  who  are  conversant  in  the  lan¬ 
guage,  but  wider  use  must  await  the  necessary  software  tools. 

In  ANNA's  case  these  tools  are  currently  under  development  at 
Stanford  University  and  in  Europe  under  the  ESPRIT  program  [ESPR85]. 
These  tools  will  allow  the  ANNA  text,  currently  hidden  from  the  Ada 
compiler,  to  be  analyzed.  An  early  version  of  these  tools  would 
check  the  syntax  of  the  ANNA  for  syntactic  correctness.  This  early 
tool  would  create  a  DIANA  [Goos83]  syntax  tree  (in  addition  to 
checking  for  simple  errors).  The  DIANA  tree  would  be  used  as  the 
input  into  later,  more  detailed  analysis  tools.  Such  an  analysis 
tool  would  convert  all  the  ANNA  statements  (as  well  as  all  the 
virtual  Ada  statements)  into  compilable  Ada  statements.  The  entire 
design  is  then  compiled,  linked  and  executed  just  like  any  other  Ada 
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program.  The  execution  of  the  design  (using  Ada's  execution  model) 
provides  additional  checks  on  the  validity  of  the  design.  If  an 
ANNA  constraint  is  violated,  the  predefined  exception 
"ANNA_EXCEPTION"  is  raised  in  the  program  unit  where  the  constraint 
is  violated. 

To  provide  designers  and  coders  guidance  with  the  use  of  ANNA 
and  its  tools,  several  large  projects  have  begun  that  will  build 
programming  environments  that  support  the  software  lifecycle, 
including  the  use  of  ANNA  as  a  PDL.  The  PROSPECTRA  [ESPR85]  project 
in  Europe  is  the  largest  example  of  this.  These  environments  would 
integrate  ANNA  tools  with  other  lifecycle  tools.  The  development  of 
these  tools  is  still  some  time  in  the  future,  although  the  MIMSY 
project  showed  that  ANNA  and  TSL  as  a  notation  is  useful  to  a  pro¬ 
ject  when  few  or  no  tools  are  available. 


4.7  TSL  TOOLS 

Also  under  development  are  the  TSL  tools  that  allow  for 
run-time  checking  of  the  Ada  task  event  sequence.  These  tools 
involve  changes  to  the  Ada  support  environment  to  create  and  manage 
the  task  event  sequence  [Helm84].  These  tools  also  make  sure  that 
Ada  tasks  place  their  events  into  this  sequence. 

The  introduction  of  TSL  statements  will  provide  the  (modified) 
Ada  support  environment  with  constraints  to  check  against  an  actual 
tasking  sequence  of  events  from  an  executing  design.  As  with  ANNA, 
the  primary  method  of  checking  the  design  becomes  the  execution  of 
the  design  itself.  Longer  range  goals  would  add  additional  design 
checking  mechanisms  such  as  symbolic  execution  to  ANNA  and  TSL.  In 
either  case,  the  use  of  executable  designs  will  be  a  sharp  contrast 
from  the  state  of  the  practice  in  the  use  of  Program  Design 
Languages . 
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SECTION  5 


MIMSY'S  USE  OF  FORMAL  METHODS 


5.1  BUHR  DIAGRAM'S  RELATIONSHIP  TO  FORMAL  METHODS 

As  discussed  in  earlier  sections,  MIMSY  used  a  design  method¬ 
ology  that  used  Ada  tasks  as  the  primary  design  paradigm,  with  Ada's 
tasking  model  used  as  the  mechanism  for  data  and  control  flow  among 
the  entities  of  the  design.  MIMSY's  designers  tried  to  follow  good 
design  practices  by  using  hierarchies  to  hide  details  of  the  design 
until  lower  levels  when  the  details  are  necessary.  In  MIMSY's  case 
Buhr  diagrams  were  constructed  with  incremental  refinement,  where  a 
top  level  diagram  was  refined  into  lower  level  Buhr  diagrams  that 
contained  more  and  more  detail. 

One  complication  that  the  designers  encountered  was  how  to 
refine  one  Buhr  diagram  into  its  lower  level  diagrams.  On  one  hand, 
the  designers  wanted  to  use  traditional  information  hiding,  placing 
only  the  minimum  amount  of  detail  necessary  in  a  higher  level.  On 
the  other  hand,  enough  detail  had  to  be  provided  to  higher  levels  of 
the  design  to  provide  enough  information  to  satisfy  the  formal 
methods  being  used.  A  system  built  with  hierarchies  will  want  to 
prove  that  important  attributes  and  behaviors  are  maintained  among 
levels  (and  so  the  entire  system).  The  information  needs  of  formal 
methods  and  data  abstraction/information  hiding  can  come  into 
conflict . 

One  example  of  where  this  conflict  arose  was  in  the  Structure 
Manager  component  in  MIMSY.  Using  the  design  methodology  lead  to  a 
decision  to  use  dynamically  created  and  terminated  tasks  in  the 
structure  manager  to  control  the  windows  and  processes  a  user  might 
create.  Initially  the  designers  hoped  that  the  implementation 
details  of  using  tasks  within  the  body  of  Structure  Manager  could  be 
hidden  from  the  caller.  Yet  the  ANNA  and  TSL  statements  that  would 
be  appearing  in  the  package  specification  for  Structure  Manager 
needed  to  know  something  about  the  behavior  and  restrictions  being 
implemented  in  the  body.  Eventually  the  users  and  designers  of 
Structure  Manager  had  to  compromise  about  how  much  information  is 
visible  in  the  package  specification. 

When  the  designers  using  Buhr  diagrams  go  from  one  level  of 
detail  to  the  next,  they  need  to  specify  the  behavior  of  the  lower 
levels  as  well  as  the  interfaces.  The  icons  in  the  Buhr  diagrams 
have  good  support  for  specifying  the  interfaces  between  levels. 
Support  for  behavior  is  not  as  strong;  some  tasking  behavior  can  be 
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described  in  the  diagrams  but  not  much  else.  As  designers  moved 
from  the  Buhr  diagrams  to  the  more  detailed  presentation  provided  by 
ANNA  and  TSL,  they  wanted  to  capture  the  intended  behavior  to  be 
implemented  in  the  lower  levels  of  the  design  without  unduly 
constraining  the  eventual  designers  and  coders  of  the  lower  levels. 

An  example  of  this  occurred  in  MIMSY  with  the  CAISette  compo¬ 
nent,  which  encapsulated  the  interface  to  the  underlying  Ada  support 
environment.  Since  many  different  components  would  be  using 
CAISette  to  access  the  support  environment,  there  were  many  assump¬ 
tions  that  designers  made  of  CAISette  that  the  eventual  coders  of 
CAISette  would  have  to  consider.  Some  of  these  issues  are  discussed 
in  detail  later.  A  compromise  used  in  MIMSY  was  to  use  virtual  ANNA 
and  TSL  statements  to  define  the  intended  behavior  of  CAISette.  The 
eventual  coders  of  CAISette  are  not  bound  to  implement  the  virtual 
Ada  constructs,  as  long  as  the  behavior  of  the  CAISette  implementa¬ 
tion  matches  the  behavior  of  the  virtual  ANNA. 

The  hierarchy  of  Buhr  diagrams  containing  MIMSY' s  design  had 
different  designers  creating  the  different  levels.  This  required 
that  the  designers  be  very  precise  in  their  designs  for  both  the 
diagrams  and  the  eventual  translation  to  ANNA/TSL  text.  The  need 
for  precise  specifications  of  the  components  would  have  been  true  if 
MIMSY  had  been  designed  from  the  bottom  up  with  reusable  Ada 
packages.  A  package  could  not  have  been  "reusable"  unless  its 
specification  provided  enough  behavioral  and  interface  information 
to  allow  a  designer  to  determine  how  (and  if)  this  package  could  be 
reused  in  the  current  design.  Designers  should  be  able  to  assess 
the  reusability  of  a  package  without  having  to  read  all  the  details 
of  that  package's  body. 


5.2  MIMSY  USED  ALGEBRAIC  SPECIFICATION  APPROACH 

As  discussed  earlier,  MIMSY  could  have  chosen  to  use  either  the 
algebraic  specification  or  the  abstract  modeling  approach  to 
abstract  data  types.  The  abstract  modeling  approach  could  have  been 
useful  to  MIMSY  in  designing  several  of  the  components.  For  exam¬ 
ple,  the  CAISette  package  controls  the  display  of  lines  of  text  on 
the  user's  screen.  The  control  and  display  characters  necessary  to 
properly  display  a  line  of  text  on  the  screen  in  its  proper  position 
could  have  been  modeled  on  sequences. 

If  a  pre-existing  data  type  called  "sequence"  existed,  CAISette 
could  have  based  the  messages  (characters)  that  are  sent  to  the 
terminal  on  the  sequence  data  type.  The  sequence  data  type  could  be 
constructed  such  that  its  axioms  proved  that  the  sequence  did  not 
allow  messages  (characters)  to  become  interspersed.  Then  the  only 
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thing  that  the  designer  of  CAISette  would  have  to  do  would  be  to 
show  that  CAISette  used  the  sequence  data  type  correctly  in  the  new 
data  types  which  controlled  the  user's  screen. 

Unfortunately  MIMSY  did  not  have  any  such  "sequence"  data  type 
to  use  in  modeling  the  new  data  types  needed  for  CAISette  and  the 
other  components.  Without  a  library  of  reusable  abstract  data  type 
models  (or  the  time  necessary  to  create  them),  MIMSY  used  the  alge¬ 
braic  specification  approach.  As  a  result,  components  such  as 
CAISette  convey  the  same  amount  of  information  about  their  restric¬ 
tions  and  behavior,  but  these  specifications  are  much  more  verbose 
than  if  simple  references  to  reusable  data  modeling  packages  had 
been  used. 

Mature  tools  and  notations  used  with  data  abstraction,  such  as 
AFFIRM  [Gerh80],  come  with  a  library  of  reusable  lower  level  data 
types.  AFFIRM  has  an  extensive  set  of  data  types  and  theorems  for 
dealing  with  sequences.  The  library  of  sequence  data  types  makes  it 
easier  for  an  AFFIRM  user  to  create  (model)  their  own  data  types, 
and  the  library  of  sequence  theorems  provides  an  AFFIRM  user  with  a 
ready  list  of  important  properties  that  the  user's  data  types  should 
satisfy. 

ANNA  users  need  to  develop  their  own  libraries  of  reusable 
abstract  models.  The  models  that  might  go  into  this  library 
(sequences,  numbering  systems,  etc.)  will  depend  on  the  applications 
that  the  users  are  designing  systems  for.  Users  must  weigh  the 
costs  of  creating  and  maintaining  such  a  library  versus  the  future 
benefits  in  savings  to  later  designs. 


5.3  MIMSY  USED  ANNA  AND  TSL  AS  THE  PDL 

MIMSY' s  designers  used  a  combination  of  ANNA  and  TSL  as  the 
Program  Design  Language  (PDL)  for  MIMSY.  MIMSY' s  design  was  done  to 
the  Preliminary  Design  level  of  detail.  As  a  result,  the  Prelimi¬ 
nary  Design  document  consisted  of  the  Buhr  diagrams  and  Ada  package 
specifications  (with  the  ANNA  and  TSL  statements  placed  in  the 
package  specification).  Only  a  limited  amount  of  information  was 
placed  in  the  package  bodies,  so  information  on  how  the  bodies  of 
the  packages  will  be  designed  is  deferred  until  Detailed  Design. 

MIMSY' s  designers  did  not  have  access  to  any  ANNA  or  TSL  tools, 
not  even  to  tools  that  would  have  checked  the  statements  for  syn¬ 
tactic  correctness.  An  Ada  compiler  was  used  to  check  Ada  state¬ 
ments,  but  the  ANNA  and  TSL  statements  were  hidden  from  it  in 
comments.  The  ANNA/TSL  statements  were  used  as  an  expressive  nota¬ 
tion  for  formally  specifying  the  design's  restrictions,  assumptions 
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and  behavior.  Any  checking  or  "execution”  of  ANNA  or  TSL  statements 
had  to  be  done  by  hand. 

One  tool  that  was  available  to  the  MIMSY  designers  was  a  modi¬ 
fied  version  of  Digital  Equipment  Corporation's  language-sensitive 
editor  "lsedit"  [DEC85a],  This  structured  editor  can  use  a  user- 
defined  template  that  defines  the  syntax  of  a  programming  language. 
The  editor  comes  with  a  template  (that  is  similar  to  a  Backus-Naur 
Form  syntax  definition)  for  the  major  languages  supported  by  the 
computer,  MIMSY' s  designers  modified  the  template  for  Ada  to 
include  additional  syntax  definitions  for  ANNA's  structured  com¬ 
ments,  Once  the  editor's  basic  functions  were  mastered,  the  addi¬ 
tional  support  for  ANNA  did  not  require  learning  any  additional 
commands.  While  the  use  of  this  editor  was  no  guarantee  of  semantic 
correctness  of  the  code,  its  template-driven  style  did  allow  MIMSY's 
designers  to  concentrate  on  the  details  of  the  design  instead  of  on 
the  details  of  ANNA's  syntax.  Users  of  an  expressive,  Ada-based  PDL 
such  as  ANNA  should  consider  using  a  good  editor  in  the  creation  of 
their  text  to  limit  the  number  of  simple  syntax  errors  that  might 
otherwise  creep  in. 

Because  the  design  team  did  not  have  any  experience  in  using 
ANNA,  a  series  of  informal  classes  and  seminars  were  held  before  the 
design  effort  began.  Fortunately,  MIMSY's  designers  had  a  good 
educational  background  in  the  formal  methods  being  used  in  MIMSY. 
Everyone  was  familiar  with  preconditions,  postconditions,  axioms, 
induction,  recursion,  etc.  The  training  consisted  of  reading  and 
then  discussing  the  ANNA  and  TSL  reference  manuals  as  well  as  some 
of  the  classic  papers  in  data  type  abstraction  by  Guttag  [Gutt78], 
This  training  reduced  the  amount  of  confusion  and  misconceptions 
that  would  have  otherwise  damaged  MIMSY's  design.  The  use  of  formal 
methods  and  notations  in  a  design  should  be  preceded  by  a  careful 
analysis  of  the  current  levels  of  experience  in  the  formal  methods 
to  be  used  and  the  formal  notations  and  tools  that  will  be  part  of 
the  design  effort. 

One  aspect  to  the  quality  of  a  design  is  the  degree  to  which 
the  design  considers  all  the  "special  cases"  that  might  occur. 
Examples  of  special  cases  include  initialization,  shut-down,  over¬ 
loading,  illegal  inputs,  etc.  The  ANNA  and  TSL  languages  have  the 
rigor  and  notation  for  expressing  all  these  special  cases.  Once  a 
designer  has  mastered  all  the  ANNA  and  TSL  constructs  that  could  be 
applied  to  an  Ada  construct  (such  as  exceptions,  packages,  tasks, 
etc.),  the  designer  tries  to  be  as  expressive  as  possible  by  seeing 
if  an  Ada  construct  needs  to  have  all  its  associated  ANNA  or  TSL 
constructs  included  with  it.  This  naturally  leads  the  designer  to 
consider  special  cases  such  as  initialization  and  termination. 
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This  tendency  may  have  been  helped  by  using  the  structured 
"lsedit"  editor.  In  using  the  editor  the  designer  is  presented  with 
a  menu  of  choices  for  which  (ANNA)  construct  is  to  be  used.  Cur¬ 
rently  this  menu  corresponds  to  the  ANNA  BNF  syntax  that  defines 
which  kinds  of  ANNA  statements  can  be  associated  with  which  kinds  of 
Ada  statements.  Often  the  different  ANNA  statements  correspond  to 
how  special  cases  are  to  be  handled.  A  more  powerful  version  of 
such  an  editor  might  organize  its  menu  explicitly  by  special  cases 
so  the  designers  are  further  encouraged  to  consider  these  cases. 

During  a  formal  review  of  a  design,  the  reviewers  will  demand 
to  see  evidence  that  important  issues  such  as  steady  state  opera¬ 
tions,  system  response  to  commands  and  special  cases  have  been 
addressed.  The  use  of  ANNA  and  TSL  and  the  PDL  provided  proof  to 
the  reviewers  that  these  issues  were  considered.  Because  the  use  of 
formal  methods  and  a  rigorous  notation  such  as  ANNA  should  limit  the 
amount  of  ambiguity  in  the  design,  the  reviewers,  designers  and 
managers  (as  well  as  future  maintainers)  should  all  be  able  to  read 
MIMSY's  PDL  and  come  away  with  the  same  understanding  of  the  system. 


5.4  USE  OF  ANNA  WITH  CAISETTE  PACKAGE 

The  interface  to  the  underlying  support  environment  (such  as 
the  operating  system)  was  encapsulated  in  the  CAISette  package. 
MIMSY's  CAISette  package  is  based  on  the  CAIS  [KIT84]  interface 
standard.  Only  those  CAIS  functions  needed  by  MIMSY  were  included 
in  CAISette;  other  CAIS  functions  were  not  included. 

One  problem  with  the  CAIS  specification  is  that  it  does  not 
fully  define  the  restrictions  and  behavior  of  the  subprogram  that 
might  be  called.  If  MIMSY's  CAISette  package  were  defined  to  the 
same  level  of  detail  as  the  CAIS  specification,  it  might  look 
something  like  the  first  package  (Figures  3  and  4)  in  Appendix  B. 

All  the  examples  in  Appendix  B  are  for  a  small  part  of  the  CAISette 
package,  in  this  case  from  the  scrolling  terminal.  Only  the  high¬ 
lights  of  this  package  are  presented. 

Figures  5  through  8  in  Appendix  B  replace  the  informal  comments 
from  the  first  example  (Figures  3  and  4)  with  ANNA  statements  that 
define  when  exceptions  are  raised,  etc.  This  second  example  is  less 
ambiguous  than  the  first.  The  second  example  provides  a  much  more 
detailed  interface  for  CAISette's  users  and  designers.  What  is 
still  missing  are  the  details  of  the  behavior  of  a  scrolling  termi¬ 
nal.  The  second  example  does  not  answer  important  questions  such  as 
whether  concurrent  output  to  the  terminal  is  serialized  or  is  inter¬ 
spersed. 
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Figures  9  and  10  in  Appendix  B  contain  just  TSL  statements  for 
the  scrolling  terminal  package.  To  save  space,  the  ANNA  statements 
from  the  second  example  are  not  repeated.  In  the  actual  CAISette 
package  specification  both  ANNA  and  TSL  statements  are  used. 

This  third  example  uses  "virtual  Ada"  to  define  a  task  type 
that  controls  the  output  requests  to  an  open  terminal.  The  messages 
being  sent  to  the  screen  (consisting  of  cursor  positioning  commands 
and  the  characters  to  be  displayed)  are  serialized  and  output  one  at 
a  time.  This  means  that  the  user  of  CAISette  does  not  have  to  worry 
about  two  tasks  sending  a  string  to  the  screen  and  having  the 
strings  being  interspersed.  One  string  will  be  output  in  its  proper 
position,  then  the  other  string  will  be  output  in  its  position. 

Note  that  the  use  of  the  "virtual"  task  does  not  force  the  body 
of  CAISette  to  be  implemented  with  a  task  to  serialize  screen  out¬ 
put.  For  example,  some  Ada  support  environments  will,  by  default, 
serialize  the  output  requests  so  the  programmer  does  not  have  to  add 
any  additional  code  to  achieve  this  behavior.  If  MIMSY  is  ever 
implemented  on  a  support  environment  that  does  not  serialize  its 
output,  then  the  "virtual"  tasks  would  likely  be  implemented  with 
real  tasks  in  the  body  of  the  CAISette  package.  This  is  another 
example  of  information  hiding  and  design  decision  deferral  until 
necessary. 


5.5  ADVANTAGES  OF  USING  FORMAL  METHODS  IN  MIMSY 

The  use  of  the  formal  methods  described  in  this  document  on 
MIMSY  lead  to  benefits  for  both  the  current  designers  and  reviewers 
of  MIMSY,  as  well  as  for  future  coders,  users  and  maintainers.  As 
with  many  of  the  proposals  for  improving  software  engineering  prac¬ 
tices,  the  increased  use  of  formal  methods  should  increase  the 
quality  and  decrease  the  overall  life  cycle  costs  of  software.  The 
use  of  formal  methods  in  this  project  should  help  MIMSY  in  achieving 
these  goals. 

By  using  a  formal  notation  as  the  PDL,  MIMSY  allows  for  the 
possibility  of  design  analysis  by  ANNA  and  TSL  tools  when  those 
tools  become  available.  One  of  MIMSY' s  requirements  was  that  it 
should  support  portability  to  other  support  environments  and  allow 
more  functions  to  be  added.  These  future  upgrades  should  be  less 
costly  and  time-consuming  if  the  maintainers  can  analyze  the  effects 
of  their  changes  (possible  introduction  of  errors  to  existing  code, 
new  and  excessive  performance  delays,  etc.)  before  the  changes  are 
committed  to  code.  Future  ANNA  tools  should  allow  for  the  creation 
of  executable  designs.  If  the  maintainers  can  begin  the  maintenance 
cycle  by  working  on  the  design  documents  (instead  of  working  from 
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the  implementation  code),  maintenance  is  more  likely  to  result  in  a 
usable  system  at  less  cost. 

One  technique  used  to  validate  system  characteristics  such  as 
the  user  interface  is  the  construction  of  a  rapid  prototype.  This 
rapid  prototype  might  be  used  by  the  customer  during  a  formal  review 
to  determine  if  the  user  interface  is  satisfactory.  If  the  customer 
finds  (through  hands-on  experience)  that  the  user  interface  is 
satisfactory,  then  the  customer  will  approve  the  interface,  and 
expect  to  see  a  similar  interface  in  the  final  system. 

One  potential  problem  with  rapid  prototypes  is  that  unless 
project  management  control  is  exercised,  the  rapid  prototype  and  the 
actual  system  can  become  two  divergent  products.  While  developed 
independently,  the  rapid  prototype  and  the  actual  system  must  remain 
compatible  (have  the  same  user  interface  behavior  for  example)  or 
else  the  knowledge  (and  customer  acceptance)  gained  from  the  rapid 
prototype  cannot  be  inserted  back  into  the  actual  system.  Since  the 
customer  will  have  used  and  approved  the  rapid  prototype,  the  cus¬ 
tomer  may  end  up  preferring  the  rapid  prototype  over  the  actual 
system. 

Part  of  MIMSY's  development  plan  calls  for  the  development  of 
rapid  prototypes  to  validate  the  user  interface  for  controlling  the 
windows  and  user  processes.  By  rigorously  defining  the  interfaces 
and  behavior  (with  ANNA  and  TSL)  of  MIMSY,  rapid  prototype  builders 
and  the  designers/coders  should  be  able  to  proceed  from  the  same 
high-level  design  document  and  not  end  with  incompatible  products. 
The  system  behavior  of  the  final  MIMSY  product  should  be  the  same  as 
the  behavior  of  the  rapid  prototype  shown  to  the  customer. 

One  way  of  validating  a  product  is  to  build  test  cases  that 
provide  inputs  to  the  system  as  well  as  to  define  what  the  expected 
outputs  should  be.  Typically  these  test  cases  are  constructed  from 
the  original  system  requirements.  These  test  cases  are  applied  to 
the  completed  system  during  final  customer  acceptance  tests.  If  the 
tests  are  successful  then  the  system  is  accepted. 

The  use  of  a  formal  specification  and  design  language  (such  as 
ANNA)  should  provide  a  more  precise  definition  of  system  behavior. 
This  should  lead  to  the  construction  of  more  comprehensive  test 
cases.  Since  the  use  of  ANNA  and  TSL  (used  with  a  good  ANNA  tool 
set)  can  produce  executable  designs,  this  allows  the  application  of 
test  cases  at  the  Preliminary  and  Detailed  Design  Reviews  as  well  as 
the  final  customer  acceptance  review.  The  early  applications  of 
these  test  cases  can  identify  problems  with  the  design  early  in  its 
life  cycle,  when  such  errors  are  cheaper  to  fix  than  during  final 
testing. 
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The  use  of  a  formal  design  notation  such  as  ANNA  should  reduce 
the  possibility  of  different  interpretations  of  the  design  docu¬ 
ments.  Already  this  section  has  shown  how  the  same  design  document 
might  be  used  by  the  designers,  coders,  rapid  prototype  builders, 
test  case  writers  and  customers.  If  the  design  documents  were  in  a 
natural  language,  each  user  of  the  document  might  read  something 
different  from  the  ambiguous  text.  A  formal  design  notation  can 
reduce  the  possibility  of  this  occurring. 


5.6  REVIEW  PROCESS  WHEN  USING  FORMAL  METHODS 

The  preliminary  design  documents,  consisting  mostly  of  ANNA/TSL 
text  and  supporting  Buhr  diagrams,  were  reviewed  by  the  "customer” 
at  a  Preliminary  Design  Review.  As  with  most  formal  reviews,  the 
design  documents  were  distributed  to  the  attendees  ahead  of  time  for 
their  review.  The  actual  review  consisted  of  a  presentation  of  the 
design  by  the  design  team,  followed  by  questions  and  comments  on  the 
design  by  the  customer. 

The  primary  medium  for  both  the  presentation  of  the  design  and 
the  customer  questions  about  the  design  were  the  ANNA  axioms  and 
pre/postconditions.  The  discussion  on  how  MIMSY  would  operate  in 
steady  state  and  exceptional  conditions  was  done  by  tracing  the  flow 
of  control  and  data  through  the  axioms.  Customer  questions  about 
the  current  state  of  the  system  or  the  assumptions  being  made  by  a 
MIMSY  component  were  answered  by  referencing  the  appropriate  axiom. 
Special  cases  are  discussed  by  tracing  the  raising  and  propagation 
of  exceptions.  The  use  of  ANNA  as  the  design  notation  eliminated 
many  of  the  questions  about  what  a  particular  sentence  of  the  design 
document  really  means. 

The  design  review  of  MIMSY  went  as  well  as  it  did  because  the 
customer  reviewers  had  a  good  background  in  both  the  formal  methods 
being  used  and  in  the  ANNA  and  TSL  languages.  As  a  result,  the 
customer  did  not  require  a  lot  of  education  before  the  design  docu¬ 
ments  were  delivered.  While  the  use  of  a  formal  notation  such  as 
ANNA  on  MIMSY  requires  high  skill  levels  of  both  the  designers  and 
the  customer,  the  advantages  gained  from  an  unambiguous  design 
offset  any  costs  from  using  skilled  people  on  the  project. 
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SECTION  6 


CONCLUSIONS 


While  the  MIMSY  project  involved  relatively  few  people  working 
on  a  project  for  a  short  time,  it  did  confirm  the  usefulness  of  for¬ 
mal  mathematical  methods  to  the  design  of  a  system.  MIMSY' s  "custo¬ 
mers"  judged  the  designs  as  being  much  more  readable  than  the  typi¬ 
cal  acquisition  design  document.  All  of  the  reviewers  felt  that 
they  were  able  to  grasp  the  functionality  as  well  as  the  behavior 
that  was  in  MIMSY' s  design. 

The  object  orientation  of  the  design  methodology  promoted 
information  hiding,  reusability  and  other  concepts  of  software 
engineering.  The  notations  provided  by  Ada,  ANNA  and  Buhr  diagrams 
all  supported  an  object  orientation.  The  Buhr  diagrams  provided  a 
high  level  graphical  representation  of  what  was  defined  in  detail  in 
the  textual  Ada,  ANNA  and  TSL. 

Formal  methods  need  to  be  applied  to  a  system's  behavior  as 
well  as  its  functionality.  Ada's  execution  model  provides  a  founda¬ 
tion  for  describing  the  behavior  of  a  system.  ANNA  and  TSL  allow 
additional  aspects  of  system  behavior  (beyond  what  Ada  provides)  to 
be  formalized. 

The  use  of  Ada's  (tasking)  model  supports  executable  designs 
and  prototypes.  There  is  no  need  to  step  outside  of  the  PDL  used 
with  MIMSY  in  order  to  create  an  executable  design  or  prototype. 

The  design  documents  and  the  prototypes  remain  compatible. 

Real-time  embedded  systems  must  be  very  robust,  able  to  respond 
to  a  wide  variety  of  inputs  and  error  conditions.  The  rigor  of  ANNA 
encouraged  designers  and  reviewers  to  cover  more  of  these  special 
cases  in  the  design. 

Building  a  design  in  hierarchies  requires  that  all  levels  of 
the  design  have  their  functionality  and  behavior  well-defined.  The 
higher  levels  of  the  design  will  be  created  according  to  assumptions 
of  the  functionality  and  behavior  of  the  lower  levels.  ANNA  and  TSL 
provide  notations  that  can  precisely  define  component  behavior.  If 
components  are  to  be  reused  in  different  designs  or  systems,  then 
their  functionality  and  behavior  must  be  precisely  defined  or  else 
that  component  will  not  be  very  reusable. 

Ada  components,  which  are  expected  to  be  extensively  reused, 
are  especially  vulnerable  to  different  interpretations  of  system 
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behavior.  The  CAIS  is  supposed  to  be  extensively  used,  yet  the 
behavior  of  a  CAIS  implementation  is  subject  to  a  variety  of  inter¬ 
pretations.  ANNA's  expressiveness  points  out  the  lack  of  behavioral 
requirements  in  existing  specifications  such  as  the  CAIS. 

Designers  and  reviewers  need  training  in  design  methodology  and 
notations  of  formal  methods.  Formal  methods  become  useful  only  when 
all  the  audiences  of  the  design  can  understand  them.  A  design  nota¬ 
tion  should  not  become  an  obstacle  to  understanding  the  system's 
design. 

Formal  methods  are  not  part  of  the  state  of  the  practice. 
Experience  in  using  formal  methods  on  real  systems  is  needed  before 
formal  methods  become  commonplace.  The  designers  of  real-time  sys¬ 
tem  have  typically  not  had  the  opportunity  to  use  formal  methods  in 
large  real  time  embedded  systems.  The  complexity  of  these  systems 
also  gives  their  designers  the  greatest  need  for  formal  methods. 

Designers  need  reusable  design  paradigms  (perhaps  from  earlier 
experiences)  which  can  be  used  with  ANNA  and  TSL.  Otherwise  the 
designers  will  have  to  start  from  scratch  when  formal  methods  are 
introduced. 

Good  ANNA  and  TSL  tools  are  needed  to  use  ANNA  on  real  work. 
Trying  to  use  formal  methods  by  hand  on  large  projects  can  be  very 
tedious  and  expensive.  A  support  environment  is  needed  to  make 
these  formal  methods  cost  effective  on  large  projects. 

MIMSY's  use  of  the  modified  "lsedit"  editor  made  using  ANNA 
easier.  This  relieved  the  designers  from  having  to  remember  all  the 
details  of  ANNA'S  syntax. 

The  use  of  formal  methods  is  only  one  part  of  the  activities 
involved  in  creating  a  large  scale  software  system.  The  other 
activities  will  have  their  own  methodologies  and  support  environ¬ 
ments.  ANNA  tools  must  be  part  of  an  overall  Ada  programming  and 
lifecycle  support  environment.  Formal  methods  should  not  be  treated 
in  isolation  but  should  instead  be  an  integral  part  of  the  design. 
This  means  configuration  management,  change  control  and  the  other 
project  activities  called  for  by  DOD-STD-2167. 

ANNA  and  TSL  do  not  address  the  design  management  information 
called  for  in  DOD-STD-2167.  This  information  is  easier  to  collect 
and  manipulate  if  it  is  kept  with  the  design  documents  (such  as  PDL) 
that  it  describes.  Users  have  to  tailor  ANNA  to  capture  design 
management  information  (change  logs,  requirements  traceability). 
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APPENDIX  A 


ANNA  EXAMPLE 
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with  SCREEN_CONTROLLER,  PROGRAM_CONTRO LLER ;  package 
STRUCTURE_MANAGER  is 

MAXIMUM_NUMBER_OF_VIEWPORTS  :  NATURAL; 
MAXIMUM_NUMBER_OF_PROCESSES  :  NATURAL; 

type  COMMAND_RECORDS  is  record 

PROCESS_NAME  :  PROCESS_NAMES ; 

VIEWPORT_NAME  :  VIEWPORT_NAMES; 

COMMAND_TYPE  :  COMMAND_TYPES ; 
end  record; 

procedure  START; 

— |  where 

—  preconditions 

—|  in  MAXIMUM_NUMBER_OF_VIEWPORTS ' DEFINED  =  FALSE  and 
—j  in  MAXIMUM_NUMBER_OF_PROCESSES' DEFINED  =  FALSE, 

—  postconditions 

—  |  out  MAXIMUM_NUMBER_OF_VIEWPORTS  = 

—  j  (TERMINAL_CAP . NUMBER_0F_LINES-2 )/2 , 

—  j  out  M AXI MUM_NUMBER_0 F_PR0CE S SE S  = 

—  j  (TERMINAL_CAP . NUMBER_0F_LINES-2 )  /  2 ; 

procedure  ANALYZE_COMMAND( COMMAND  RECORD:  in  COMMAND_RECORDS) ; 
— |  where 

—  preconditions 

—|  in  MAXIMUM_NUMBER_OF_VIEWPORTS' DEFINED  =  TRUE  and 
—j  in  MAXIMUM_NUMBER_OF_PROCESSES' DEFINED  =  TRUE, 

procedure  TERMINATE_ALL ; 

— |  where 

—j  out  SCREEN_CONTROLLER . NUMBER_OF_VIEWPORTS  =  0  and 

—  j  PROGRAM  CONTROLLER. NUMBER  OF  PROCESSES  =  0; 


Figure  1.  ANNA  Example:  Preconditions  and  Postconditions 
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—  axiom 

--  for  all  SM  :  STRUCTURE_MANAGER'TYPE;  C  :  COMMAND_RECORDS  => 

STRUCTURE_MANAGER'INITIAL.MAXIMUM_NUMBER_OF_VIEWPORTS 'DEFINED 
=  FALSE, 

STRUCTURE_MANAGER'INITIAL.MAXIMUM_NUMBER_OF_PROCESSES 'DEFINED 
=  FALSE, 

SM[ANALYZE_COMMAND(C) ] .MAXIMUM_NUMBER_OF_VIEWPORTS  = 

SM . MAXIMUM_NUMBER_OF_VIE WPORTS , 

SM[ANALYZE_COMMAND(C) ] .MAXIMUM_NUMBER_OF_PROCESSES  = 
SM.MAXIMUM_NUMBER_OF_PROCESSES , 

SM[TERMINATE_ALL] . SCREEN_CONTROLLER. NUMBER_OF_VlEWPORTS  =  0, 

—  SM[TERMINATE_ALL] . PROGRAMjCONTROLLER. NUMBER_OF_PROCESSES  =  0; 

end  STRUCTURE  MANAGER; 


Figure  2.  ANNA  Example:  Package  Axioms 
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APPENDIX  B 


CAISETTE  EXAMPLE 
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package  CAISETTE  is 

package  CAIS_SCROLL_TERMINAL  is 
— / 

— /  DESCRIPTION: 

— /  This  package  encapsulates  all  the  functions  necessary  to 
— /  control  a  CRT  scrolling  terminal  such  as  a  VTlOO-class 
— /  terminal.  The  terminal  must  be  capable  of  supporting 
— /  direct  cursor  addressing  and  be  able  to  output  bold 
— /  (highlighted)  as  well  as  normal  characters. 

procedure  OPEN  (TERMINAL  :  in  FILE_TYPE  ; 

NODE  :  out  N0DE_TYPE ; 

MODE  :  in  FILE_M0DE  :=  INOUT_FILE); 

—  raise  STATUS_ERROR  if  the  terminal  is  already  open 

—  will  open  the  terminal  and  pass  the  NODE  back  to  caller 

procedure  CLOSE  (NODE  :  in  N0DE_TYPE) ; 

—  raise  STATUS_ERROR  if  NODE  isn't  an  open  terminal 

—  will  close  terminal,  preventing  any  further  output 

—  attempts 

procedure  SETPOSITION  (NODE  :  in  NODETYPE; 

POSITION  :  in  P0SITI0N_TYPE) ; 

—  NODE  must  be  a  currently  open  terminal 

—  will  move  the  terminal's  cursor  to  the  position  given 


Figure  3.  CAISette  Without  ANNA  or  TSL  (OPEN  and  CLOSE) 
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procedure  PUT  (NODE  :  in  NODETYPE; 

ITEM  :  in  CHARACTER); 

—  puts  a  character  on  terminal's  screen  at  current 

—  cursor  position.  NODE  must  be  an  open  terminal. 

procedure  PUT  (NODE  :  in  N0DE_TYPE; 

ITEM  :  in  STRING); 

—  puts  a  string  on  screen  at  current  cursor  position. 
—  NODE  must  be  an  open  terminal. 

end  CAIS_SCROLL  TERMINAL; 

private 

type  NODETYPE  is  new  TBD;  end  CAISETTE; 


Figure  4.  CAISette  Without  ANNA  or  TSL  (PUT) 
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package  CAISETTE  is 

package  CAI S_SCROLL_TERMINAL  is 
— / 

— /  DESCRIPTION: 

— /  This  package  encapsulates  all  the  functions  necessary  to 
— /  control  a  CRT  scrolling  terminal  such  as  a  VTlOO-class 
— /  terminal.  The  terminal  must  be  capable  of  supporting 
— /  direct  cursor  addressing  and  be  able  to  output  bold 
— /  (highlighted)  as  well  as  normal  characters. 

procedure  OPEN  (TERMINAL  :  in  FILE_TYPE  ; 

NODE  :  out  NODE_TYPE ; 

MODE  :  in  FILE_MODE  :=  INOUT_FILE); 

— |  where 

—  preconditions 

—  TERMINAL_EXI STS (TERMINAL)  /=  TRUE  => 

raise  INTENTIONVIOLATION, 

—  TERMINAL_NOW_OPEN( TERMINAL)  /=  TRUE  => 
raise  STATUS_ERROR, 

—  exceptions  will  not  affect  package  state 

—  |  raise  INTENTION  VIOLATION  => 

—|  CAIS_SCROLL_TERMINAL  =  in  CAIS_SCROLL_TERMINAL, 

—  j  raise  STATUS_ERROR  => 

—j  CAI S_SCROLL_TERMINAL  =  in  CAIS_SCROLL_TERMINAL, 

—  postconditions 

—|  out  TERMINAL_NOW_OPEN( TERMINAL)  =  TRUE, 

—j  out  CURRENT_NODE( TERMINAL)  =  NODE; 


Figure  5.  CAISette  Example  With  ANNA  (OPEN) 
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procedure  CLOSE  (NODE  :  in  NODETYPE); 

— |  where 

—  preconditions 

—|  not  exist  T  :  FILE_TYPE  =>  CURRENT_NODE(T)  =  NODE  and 
—I  TERMINALNOVOPEN ( T )  =  TRUE  =>  raise  STATUS_ERROR, 

— |  raise  STATUS_ERROR  => 

—I  CAI S_SCROLL_TERMINAL  =  in  CAI S_SCROLL_TERMINAL , 

—  postconditions 

—  |  out  TERMINAL_NOW_OPEN(T)  =  FALSE, 

—j  out  CURRENT_POSITION  =  (ROW  =>  1,  COLUMN  =>  1); 

— |  axiom 

—j  for  all  P  :  CAIS_SCROLL_TERMINAL ' TYPE ;  S,T  :  FILE_TYPE; 

—  j  N,M  :  NODE_TYPE ;  D  :  OPEN_DISPLAY  => 

basis  step,  initially  no  terminals  are  open 

—  |  CAI S_SCROLL_TERMINAL 'INITIAL . TERMINAL_NOW_0  PEN( T )  =  FALSE, 

induction  step,  if  terminal  last  mentioned  in  OPEN  then  the 
terminal  is  still  open,  if  last  mentioned  in  CLOSE  then 
the  terminal  still  closed. 

—  |  P [ OPEN (S,N)]. TERMINAL  NOW  OPEN(T)  = 

—j  if  S  =  T  then  TRUE  else  P.TERMINAL_NOW_OPEN(T) , 

—  j  P[OPEN(S,N)].CURRENT_NODE(T)  = 

—  j  if  S  =  T  then  N  else  P.CURRENT_NODE(T) , 

—  j  P[CLOSE(N)].TERMINAL_NOW_OPEN(T)  = 

— j  if  exist  U  :  FILE_TYPE  =>  CURRENT_NODE(U)  =  M  and  N  =  M 
— j  and  U  =  T  then  FALSE  else  P.TERMINALNOWOPEN(T) , 

— j  P[CLOSE(N)]. CURRENT  POSITION  =  (ROW  =>  1,  COLUMN  =>  1), 


Figure  6.  CAISette  Example  With  ANNA  (CLOSE) 
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in  NODE_TYPE ; 
in  POSITION  TYPE); 


procedure  SET_POSITION  (NODE 

POSITION 

where  —  preconditions 

not  exist  T  :  FILE_TYPE  =>  CURRENT_NODE ( T )  =  NODE  and 
TERMINAL_NOW_OPEN ( T )  =  TRUE  =>  raise  STATUS_ERROR, 

POSITION. ROW  >  SCREEN_SIZE. ROW  or  POSITION. COLUMN  > 
SCREEN_SIZE. COLUMN  =>  raise  LAYOUT_ERROR ,  —  postconditions 
out  CURRENT_POSITION . ROW  =  POSITION. ROW  and 
CURRENT_POSITION. COLUMN  =  POSITION. COLUMN; 
function  UPDATE_POSITION  (POSITION  :  POSITION_TYPE ; 

ITEM  :  CHARACTER)  return  POSITIONTYPE; 
where  return  P  :  POSITIONTYPE  => 
if  ITEM  =  ASCII. BS 
then  if  POSITION. COLUMN  >  1 
then  P. COLUMN  =  POSITION. COLUMN  -  1 
else  P. COLUMN  =  POSITION. COLUMN 
endif 


P.ROW  =  POSITION. ROW 

else  if  ITEM  =  ASCII. LF 

then  if  POSITION. ROW  <  SCREEN_SIZE.ROW 

then  P.ROW  =  POSITION. ROW  +  1 

else  P.ROW  =  POSITION. ROW 

endif 

P. COLUMN  =  POSITION. COLUMN 
endif 

else  if  ITEM  =  ASCII. CR 
then  P. COLUMN  =  1 
P.ROW  =  POSITION. ROW 
endif 

else  if  ITEM  =  ASCII. HT 

then  P.COLUMN=P. COLUMN  +  8  -  ((P. COLUMN  -  1)  mod  8) 

P.ROW  =  POSITION. ROW 

endif 

else  if  ITEM  >=  ASCII. SP  and  ITEM  <=  ASCII. TILDA 
then  P. COLUMN  =  POSITION. COLUMN  +  1 
P.ROW  =  POSITION. ROW 
endif 

else  P  =  POSITION 
endif 


Figure  7.  CAISette  Example  With  ANNA  (SET_POSITION) 
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procedure  PUT  (NODE  :  in  NODE_TYPE ; 

ITEM  :  in  CHARACTER); 

— |  where 

—  preconditions 

—|  not  exist  T  :  FILE_TYPE  =>  CURRENT  NODE(T)  =  NODE  and 
—j  TERMINAL_NOW_OPEN(T)  =  TRUE  =>  raise  STATUS_ERROR, 

—  postconditions 

—  |  out  CURRENT_POSITION  = 

—  j  UPDATE_POSITION ( CURRENT_POSITION , ITEM ) ; 

procedure  PUT  (NODE  :  in  NODE_TYPE; 

ITEM  :  in  STRING); 

— |  where 

—  preconditions 

—  |  not  exist  T  :  FILE  TYPE  =>  CURRENT  NODE(T)  =  NODE  and 
—j  TERMINAL_NOV_OPEN(T)  =  TRUE  =>  raise  STATUS_ERROR , 

—  postconditions  (see  axioms,  uses  recursion  of  PUT(char) 


— |  axiom 

—  |  for  all  P  :  CAI S_SCROLL_TERMINAL ' TYPE ;  N  :  NODE_TYPE ; 

—  j  C,  D  :  CHARACTER;  S  :  STRING  => 

—  strings  are  output  as  characters  with  head  recursion 

—|  P[PUT(C  &  S)]  =  P[PUT(C) ; UPDATE_POSITION( CURRENT  POSITION); 

—  I  PUT(S)  ] , 

—  j  P[PUT(C  &  D) ]  =  P[PUT(C) ;UPDATE_POSITION(CURRENT_POSITION) ; 

— j  PUT(D) ;UPDATE_POSITION( CURRENT  POSITION) ] ; 

end  CAIS  SCROLL  TERMINAL; 


private 

type  NODE  TYPE  is  new  TBD;  end  CAISETTE; 


Figure  8.  CAISette  Example  With  ANNA  (PUT) 
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package  CAISETTE  is 

package  CAIS_SCROLL  TERMINAL  is 
— / 

— /  DESCRIPTION: 

— /  This  package  encapsulates  all  the  functions  necessary  to 
— /  control  a  CRT  scrolling  terminal  such  as  a  VTlOO-class 
— /  terminal.  The  terminal  must  be  capable  of  supporting 
— /  direct  cursor  addressing  and  be  able  to  output  bold 
— /  (highlighted)  as  well  as  normal  characters. 

— :  task  type  DISPLAY_EMULATOR  is 
— :  entry  PUT  (ITEM  :  in  CHARACTER); 

— :  entry  FINISHED; 

— :  end  DI SPLAY_EMULATOR ; 

— :  type  0PENED_DI SPLAY  is  access  DI S PLAY_EM U LATOR ; 

procedure  OPEN  (TERMINAL  :  in  FILE_TYPE  ; 

NODE  :  out  N0DE_TYPE ; 

MODE  :  in  FILE_M0DE  :=  INOUT_FILE); 

— +  when  OPEN  activates  ?E  where  E  is  of  type 
— +  DISPLAY_EMULATOR  then  ?E  running 

— +  before  ?E  accepts  at  PUT; 

procedure  CLOSE  (NODE  :  in  N0DE_TYPE) ; 

— +  when  not  ?P  calling  ?E  at  PUT 

— +  where  ?P  is  of  type  CAI S_SCROLL_TERMINAL . PUT 

— +  and  ?E  is  of  type  DISPLAY_EMULATOR 

— +  then  CLOSE  calling  ?E  at  FINISHED 

— +  before  ?E  terminated; 

procedure  SETPOSITION  (NODE  :  in  N0DE_TYPE; 

POSITION  :  in  P0SITI0N_TYPE) ; 

— +  when  ?E  accepts  SET_P0SITI0N  at  PUT 
— +  where  E  is  of  type  DISPLAY_EMULATOR 

— +  then  POSITIONING_STRING' LENGTH  occurences  of 

— +  (?E  accepts  PUT  =>  ?E  releases  PUT)  before  ?E 

— +  releases  SET  POSITION; 


Figure  9.  CAISette  Example  With  TSL  (OPEN  and  CLOSE) 
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procedure  PUT  (NODE  :  in  N0DE_TYPE; 

ITEM  :  in  CHARACTER); 

— +  when  ?E  accepts  CAIS_SCROLL_TERMINAL. PUT  at  PUT 
— +  where  E  is  of  type  DISPLAYEMULATOR 

— +  and  where  GRAPHIC_RENDITION_SUPPORT  =  BOLD  then 

— +  BEGIN_BOLD' LENGTH  +  1  +  END_B0LD' LENGTH  occurences  of 

— +  (?E  accepts  PUT  =>  ?E  releases  PUT)  before 

— +  ?E  releases  CAIS  SCROLL  TERMINAL. PUT; 

procedure  PUT  (NODE  :  in  N0DE_TYPE; 

ITEM  :  in  STRING); 

— +  when  ?E  accepts  CAIS_SCROLL_TERMINAL. PUT  at  PUT 
— +  where  E  is  of  type  DISPLAY_EMULATOR 

— +  and  where  GRAPHIC_RENDITION  SUPPORT=PRIMARY_RENDITION 

— +  then  ITEM' LENGTH  occurences  ol  (?E  accepts  PUT  => 

— +  ?E  releases  PUT) 

— +  before  ?E  releases  CAISSCROLLTERMINAL. PUT; 

— +  when  ?E  accepts  CAIS_SCROLL_TERMINAL. PUT  at  PUT 

— +  where  E  is  of  type  DISPLAY_EMULATOR 

— +  and  where  GRAPHIC_RENDITION_SUPPORT  =  BOLD  then 

— +  BEGINBOLD' LENGTH  +  ITEM' LENGTH  +  ENDBOLD' LENGTH 

— +  occurences  of  (?E  accepts  PUT  =>  ?E  releases  PUT)  before 

— +  ?E  releases  CAIS_SCROLL_TERMINAL.PUT; 

end  CAIS  SCROLL  TERMINAL;  end  CAISETTE; 


Figure  10.  CAISette  Example  With  TSL  (PUT) 
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